The invention generally relates to communication and network elements, methods, apparatuses, systems and programs e.g. for securing communication or data connection etc, using cryptograhic keys.
To secure communication over networks, cryptographic algorithms may be used. Symmetrical cryptographic algorithms may use a value called key (for example a string of e.g. 128 bits) to perform operations on the information to be secured.
Such operations may encrypt the information and/or compute a message authentication code for e.g. a message or more generally a piece of the information. Only parties in possession of the key are able to decrypt the information, or to verify the message authentication code, which ensures that the information has not been altered during transport and has been composed by a party in possession of the key.
Depending on the cryptographic algorithm, sometimes more than one key may be necessary to protect the communication. As an example, a key may be provided for encryption and another key for authentication. There are mechanisms that allow deriving several keys from a single key, sometimes called master key. One example is a secure transport protocol such as a real-time transport protocol, SRTP, e.g. according to RFC3711. Here, a (secret) 128 bit master key and a (not necessarily secret) 112 bit so called master salt are used to derive several keys needed to apply encryption and authentication to a communication based on a real-time transport protocol plus a real-time transport control protocol (e.g. according to RFC3560). Key derivation can be done using pseudo random functions or hash functions. For a given input, such functions produce an output which cannot be computed by a party that does not know the full input. Different keys can be derived from a master key by applying such a function to different strings composed from different constants and the master key. Various pseudo random functions and hashfunctions are described in the literature and in standardization documents such as a function PRF_n in RFC3711.
For securing communication between two parties with symmetrical cryptography, at least one key is established between the parties. The two parties agree on a common key to be used. Reusing such a key over and over may allow attackers to find ways to break the key, so this key should be changed often. Mostly, at the beginning of a new communication session, a new common key may be established.
Using one master key to derive keys to secure different traffic flows (e.g. within a point-to-point voice call, the flow from party A to B as well as the flow from party B to A) may expose the encryption to certain attacks. E.g. in SRTP, a so called “SSRC collision” may happen, leading to a so called “two-time-pad” which may allow an attacker that has access to the encrypted communication to break the encryption (see RFC3560 and RFC3711 for a description.) In such cases, usage of different master keys for the traffic of different senders is more secure. So, in a point-to-point voice call using SRTP, two master keys may be established, one for the flow from party A to B and another master key for the flow from party B to A.
Many procedures have been described how to establish a common key over an insecure network. Some of them require that communicating parties have a “preshared key”, i.e. a common secret established “offline”, others require public key cryptography and a public key infrastructure, PKI, where communicating parties own so called “public/private key” pairs, and trusted third parties certify the identity of the owners of key pairs. Approaches relying on shared keys do not scale. The PKI approach, on the other hand, is a “heavy weight” approach that requires much effort. A PKI for servers, e.g. WWW servers, exists in the current Internet. Its effectiveness suffers considerably from the fact that end users mostly cannot know whether they can trust a given certificate authority. PKIs comprising public/private key pairs for each end user have not been deployed in a large scale up to now. Public key cryptography typically comprises expensive computations, which might be undesirable on certain devices, like cell phones etc.
In an environment providing secure signalling allowing secure key exchange such as e.g. a scenario using a protocol for initiating a session such as session initiation protocol, SIP, a number of key exchange mechanisms have been proposed as described in Requirements and Analysis of Media Security Management Protocols, D. Wing, Ed., “draft-ietf-sip-media-security-requirements-04”, Mar. 20, 2008.
A straightforward and light weighted approach is session description protocol, SDP, security descriptions (SDES, RFC4568). In SDES, a caller selects a master key for protecting the media traffic it is going to send and transmits this key in an INVITE message. A called party that accepts this invitation also selects a master key for protecting the media traffic it sends and transmits this key e.g. in a 200 OK message. This approach suffers from forking/retargeting problem; and a stream sent by the caller can be successfully attacked by endpoints that did not respond to the original INVITE. This approach does not support early media. A more detailed description of forking and retargeting can be found in the above literature.
A variant of the SOGS-approach has been described in a now expired interne draft (/LD-SDES-EMI), where me caller provides the master key also for the traffic sent by the called party. This approach is called “SOES-EM” in the field. EM stands for “early media”, referring to the ability of the approach to support early media. This approach suffers from the forking/retargeting problem; the streams sent by the caller and by the endpoints that participate in the session can be successfully attacked by endpoints that did not respond to the original INVITE. An additional disadvantage of this approach is, that if the called party is a multicast sender (e.g. the caller dials into a media bridge), efficient multicast is not possible, as the multicast sender must use an individual key for the stream towards each caller.
Another approach is the one called “MIKEY-Null”. The caller provides master keys for the flows in both directions. This is similar to SDES-EM, and it suffers from the same disadvantages.
Other approaches described in the above literature are less efficient, as they involve additional cryptography, in most cases even public cryptography and/or DH key exchanges. These approaches apply such techniques because they do not assume a secure signaling infrastructure. Note that some approaches do not use a signaling infrastructure at all but perform the key exchange over the insecure media path. Another weakness of some of these approaches is that they rely on shared secrets or public/private key pairs. In case of forking/retargeting, the session invitation may reach endpoints, where such credentials are not available, and the session establishment fails. It may be intended that the session establishment fails in this case; however, there are clearly scenarios, where the intention of the caller is to be able to reach whoever the call is forked or retargeted to, but still wishes to protect the call against other parties.
One of the approaches described in the above literature provides a mode, where the called party provides the master keys for both directions. It is called MIKEY-RSA-R and described in RFC4738. This approach uses public key cryptography for securing the transmission of the master keys. It supports forking and retargeting, and also a case where the called party is a multicast sender. If however the calling party is a multicast sender, efficient multicast is not possible. A more detailed description of multicast in a SIP environment can be found in the above literature where it is described as “shared key conferencing”. Early media is not supported.
Some key exchange mechanisms involve a so called Diffie-Hellman (DH) key exchange, a procedure that allows to securely establish a common key between two parties even in the presence of attackers that monitor the complete key exchange. A DH key exchange requires expensive computations on both peers.